Điểm khác biệt với HTTP

Các URL HTTPS bắt đầu bằng "https://" và sử dụng cổng 443 theo mặc định, trong khi các URL HTTP bắt đầu bằng "http://" và sử dụng cổng 80 theo mặc định.

HTTP không được mã hóa và do đó dễ bị tấn công kẻ trung gian và nghe trộm, có thể cho phép những kẻ tấn công có quyền truy cập vào tài khoản trang web và thông tin nhạy cảm, đồng thời sửa đổi trang web để đưa phần mềm độc hại hoặc quảng cáo vào. HTTPS được thiết kế để chống lại các cuộc tấn công như vậy và được coi là an toàn trước chúng (ngoại trừ việc triển khai HTTPS sử dụng các phiên bản SSL không dùng nữa).

Các tầng mạng

HTTP hoạt động ở tầng cao nhất của mô hình TCP/IP — tầng ứng dụng ; cũng như giao thức bảo mật TLS (hoạt động như một tầng con thấp hơn của cùng một tầng), mã hóa một thông điệp HTTP trước khi truyền và giải mã một thông báo khi đến. Nói một cách chính xác, HTTPS không phải là một giao thức riêng biệt, mà đề cập đến việc sử dụng HTTP thông thường qua kết nối SSL/TLS được mã hóa .

HTTPS mã hóa tất cả nội dung gửi đi, bao gồm tiêu đề HTTP và dữ liệu yêu cầu / phản hồi. Ngoại trừ cuộc tấn công mật mã CCA có thể xảy ra được mô tả trong phần giới hạn bên dưới, kẻ tấn công ít nhất phải có thể phát hiện ra rằng kết nối đang diễn ra giữa hai bên, cùng với tên miền và địa chỉ IP của họ.

Thiết lập máy chủ

Để chuẩn bị máy chủ web chấp nhận kết nối HTTPS, quản trị viên phải tạo chứng chỉ khóa công khai cho máy chủ web. Chứng chỉ này phải được ký bởi tổ chức phát hành chứng chỉ đáng tin cậy để trình duyệt web chấp nhận nó mà không cần cảnh báo. Cơ quan có thẩm quyền xác nhận rằng chủ sở hữu chứng chỉ là người điều hành máy chủ web cung cấp nó. Các trình duyệt web thường được phân phối với một danh sách các chứng chỉ đã ký của các cơ quan cấp chứng chỉ chính để cơ quan cấp chứng chỉ có thể xác minh các chứng chỉ do các trình duyệt ký.

Nhận chứng chỉ

Một số tổ chức cung cấp chứng chỉ thương mại tồn tại, cung cấp chứng chỉ SSL / TLS trả phí thuộc một số loại, bao gồm cả Chứng chỉ xác thực mở rộng.

Let's Encrypt, ra mắt vào tháng 4 năm 2016, [28] cung cấp dịch vụ tự động và miễn phí cung cấp chứng chỉ SSL/TLS cơ bản cho các trang web. [29] Theo Electronic Frontier Foundation, Let's Encrypt sẽ giúp việc chuyển đổi từ HTTP sang HTTPS "dễ dàng như đưa ra một lệnh hoặc nhấp vào một nút." [30] Phần lớn các nhà cung cấp dịch vụ lưu trữ web và đám mây hiện tận dụng Let's Encrypt, cung cấp chứng chỉ miễn phí cho khách hàng của họ.

Sử dụng như cách kiểm soát truy cập

HTTPS cũng có thể được sử dụng để xác thực máy khách nhằm giới hạn quyền truy cập vào máy chủ web đối với người dùng được ủy quyền. Để làm điều này, quản trị viên trang web thường tạo chứng chỉ cho mỗi người dùng, chứng chỉ này người dùng tải vào trình duyệt của họ. Thông thường, chứng chỉ chứa tên và địa chỉ e-mail của người dùng được ủy quyền và được máy chủ tự động kiểm tra trên mỗi kết nối để xác minh danh tính của người dùng, thậm chí có thể không yêu cầu mật khẩu.

Trong trường hợp khóa bí mật (riêng tư) bị lộ

Một đặc tính quan trọng trong bối cảnh này là tính bảo mật chuyển tiếp hoàn hảo (PFS). Sở hữu một trong những khóa bí mật bất đối xứng dài hạn được sử dụng để thiết lập phiên HTTPS sẽ không giúp dễ dàng hơn trong việc lấy khóa phiên ngắn hạn để sau đó giải mã cuộc hội thoại, ngay cả sau đó. Trao đổi khóa Diffie-Hellman (DHE) và trao đổi khóa đường cong ellip Diffie-Hellman (ECDHE) là những chương trình duy nhất được biết đến là có thuộc tính đó vào năm 2013. Trong năm 2013, chỉ có 30% phiên trình duyệt Firefox, Opera và Chromium và gần 0% phiên Safari của Apple và Microsoft Internet Explorer sử dụng nó. [31] TLS 1.3, được đưa ra vào tháng 8 năm 2018, đã bỏ hỗ trợ cho mật mã mà không có bí mật chuyển tiếp. Tính đến tháng 2 năm 2020[cập nhật] , 96,6% máy chủ web được khảo sát hỗ trợ một số hình thức bảo mật chuyển tiếp và 52,1% sẽ sử dụng bảo mật chuyển tiếp với hầu hết các trình duyệt. [32]

Một chứng chỉ có thể bị thu hồi trước khi hết hạn, chẳng hạn như vì tính bí mật của khóa cá nhân đã bị xâm phạm. Các phiên bản mới hơn của các trình duyệt phổ biến như Firefox, [33] Opera, [34] và Internet Explorer trên Windows Vista [35] triển khai Giao thức Trạng thái Chứng chỉ Trực tuyến (OCSP) để xác minh rằng đây không phải là trường hợp. Trình duyệt gửi số sê-ri của chứng chỉ đến tổ chức phát hành chứng chỉ hoặc người được ủy quyền của tổ chức đó qua OCSP (Giao thức trạng thái chứng chỉ trực tuyến) và tổ chức này sẽ phản hồi, thông báo cho trình duyệt biết chứng chỉ có còn hợp lệ hay không. [36] CA cũng có thể cấp CRL để cho mọi người biết rằng các chứng chỉ này đã bị thu hồi.

Các giới hạn

Mã hóa SSL (Secure Sockets Layer) và TLS (Transport Layer Security) có thể được cấu hình ở hai chế độ: đơn giản và tương hỗ . Trong chế độ đơn giản, xác thực chỉ được thực hiện bởi máy chủ. Phiên bản tương hỗ yêu cầu người dùng cài đặt chứng chỉ máy khách cá nhân trong trình duyệt web để xác thực người dùng. [37] Trong cả hai trường hợp, mức độ bảo vệ phụ thuộc vào tính đúng đắn của việc triển khai phần mềm và các thuật toán mã hóa sử dụng.

SSL/TLS không ngăn chặn việc lập chỉ mục trang web bởi trình thu thập thông tin và trong một số trường hợp, URI của tài nguyên được mã hóa có thể được suy ra bằng cách chỉ biết kích thước yêu cầu / phản hồi bị chặn. [38] Điều này cho phép kẻ tấn công có quyền truy cập vào bản rõ (nội dung tĩnh có sẵn công khai) và văn bản được mã hóa (phiên bản được mã hóa của nội dung tĩnh), cho phép tấn công bằng mật mã .

Vì TLS hoạt động ở cấp độ giao thức thấp hơn HTTP và không có kiến thức về các giao thức cấp độ cao hơn, máy chủ TLS chỉ có thể hiển thị đúng một chứng chỉ cho một tổ hợp địa chỉ và cổng cụ thể. [39] Trước đây, điều này có nghĩa là không khả thi khi sử dụng dịch vụ lưu trữ ảo dựa trên tên với HTTPS. Có một giải pháp được gọi là Chỉ báo tên máy chủ (SNI), sẽ gửi tên máy chủ đến máy chủ trước khi mã hóa kết nối, mặc dù nhiều trình duyệt cũ không hỗ trợ tiện ích mở rộng này. Hỗ trợ cho SNI có sẵn kể từ Firefox 2, Opera 8, Apple Safari 2.1, Google Chrome 6 và Internet Explorer 7 trên Windows Vista . [40] [41] [42]

Theo quan điểm kiến trúc hệ thống:

• Kết nối SSL/TLS được máy tính đầu tiên khởi tạo kết nối TLS quản lý. Nếu vì bất kỳ lý do nào (định tuyến, tối ưu hóa lưu lượng, v.v.), máy chủ này không phải là máy chủ ứng dụng và nó phải giải mã dữ liệu, thì phải tìm ra các giải pháp để truyền thông tin xác thực người dùng hoặc chứng chỉ tới máy chủ ứng dụng, cần phải biết ai sẽ được kết nối.
• Đối với SSL/TLS có xác thực lẫn nhau, phiên SSL/TLS được máy chủ đầu tiên khởi tạo kết nối quản lý. Trong các tình huống mã hóa phải được phổ biến dọc theo các máy chủ chuỗi, việc quản lý session timeOut trở nên cực kỳ khó thực hiện.
• Bảo mật là tối đa với SSL/TLS tương hỗ, nhưng ở phía máy khách, không có cách nào để kết thúc đúng cách kết nối SSL/TLS và ngắt kết nối người dùng ngoại trừ bằng cách đợi phiên máy chủ hết hạn hoặc bằng cách đóng tất cả các ứng dụng máy khách liên quan.

Một kiểu tấn công man-in-the-middle tinh vi được gọi là tước đi SSL đã được trình bày tại Hội nghị Blackhat năm 2009. Kiểu tấn công này đánh bại sự bảo mật do HTTPS cung cấp bằng cách thay đổi liên kết https: thành liên kết http: :, lợi dụng thực tế là ít người dùng Internet thực sự nhập "https" vào giao diện trình duyệt của họ: họ truy cập vào một trang web an toàn bằng cách nhấp vào một liên kết và do đó bị đánh lừa rằng họ đang sử dụng HTTPS trong khi thực tế là họ đang sử dụng HTTP. Sau đó kẻ tấn công giao tiếp với khách hàng. [43] Điều này đã thúc đẩy sự phát triển của một biện pháp đối phó trong HTTP được gọi là HTTP Strict Transport Security.

HTTPS đã được chứng minh là dễ bị tấn công bởi một loạt các cuộc tấn công phân tích lưu lượng . Các cuộc tấn công phân tích lưu lượng là một loại tấn công kênh phụ dựa trên các biến thể về thời gian và kích thước của lưu lượng truy cập để suy ra các thuộc tính về chính lưu lượng được mã hóa. Có thể phân tích lưu lượng vì mã hóa SSL / TLS thay đổi nội dung của lưu lượng, nhưng có tác động tối thiểu đến quy mô và thời gian của lưu lượng. Vào tháng 5 năm 2010, một bài báo nghiên cứu của các nhà nghiên cứu từ Microsoft Research và Đại học Indiana đã phát hiện ra rằng dữ liệu người dùng nhạy cảm chi tiết có thể được suy ra từ các kênh phụ như kích thước gói. Các nhà nghiên cứu phát hiện ra rằng, mặc dù có được bảo vệ HTTPS trong một số ứng dụng web hàng đầu, cao cấp trong lĩnh vực chăm sóc sức khỏe, thuế, đầu tư và tìm kiếm trên web, kẻ nghe trộm có thể suy ra bệnh/thuốc /phẫu thuật/ thu nhập gia đình và bí mật đầu tư của người dùng. [44] Mặc dù công trình này đã chứng minh tính dễ bị tổn thương của HTTPS đối với phân tích lưu lượng, nhưng cách tiếp cận mà các tác giả trình bày yêu cầu phân tích thủ công và tập trung đặc biệt vào các ứng dụng web được HTTPS bảo vệ.

Thực tế là hầu hết các trang web hiện đại, bao gồm Google, Yahoo !, và Amazon, sử dụng HTTPS gây ra sự cố cho nhiều người dùng khi cố gắng truy cập các điểm phát Wi-Fi công cộng, vì trang đăng nhập điểm phát Wi-Fi không tải được nếu người dùng cố gắng mở tài nguyên HTTPS. [45] Một số trang web, chẳng hạn như neverssl.com và nonhttps.com, đảm bảo rằng chúng sẽ luôn có thể truy cập được bằng HTTP. [46] [47]